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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This memo defines how ILMI-based Server Discovery, which provides a 
method for ATM-attached hosts and routers to dynamically determine 
the ATM addresses of servers, shall be used to locate ATMARP servers. 


1. Introduction 


Presently, configuring a host or router to use ATMARP [1] is 
cumbersome and error-prone since it requires at least one ATM address 
to be statically configured on each host or router in the network. 
Further, it is impossible to implement a diskless host to use ATMARP 
since local configuration is required. ILMI-based Server Discovery, 
hereafter referred to as "server discovery," provides a solution to 
these problems. 


A brief overview of the Integrated Local Management Interface (ILMI) 
and the Service Registry MIB, as defined by the ATM Forum, are 
provided in this memo. The reader should consult [2] for a complete 
description of ILMI and this MIB, but the information contained here 
is sufficient for an understanding of its use to support ATMARP 
server discovery. 


2. Integrated Local Management Interface 
The Integrated Local Management Interface (ILMI) [2] provides a 
mechanism for ATM-attached devices, such as hosts, routers, and ATM 


switches, to transfer management information. It is based on the 
Simple Network Management Protocol (SNMP), Version 1, and supports 
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get, get-next, set and trap operations. 


The ILMI specification designates the switch side of the ATM link as 
the ’network side’ and the host/router side of the ATM link as the ’ 
user side.’ The Service Registry MIB, which is outlined in Section 3, 
is implmented on the network side and is queried from the user side. 


3. ILMI 4.0 Service Registry MIB 
Server discovery utilizes the Service Registry MIB defined by the ATM 
Forum in ILMI Specification Version 4.0 [2]. To support the existing 
framework for IP over ATM, ATM switches must support the Service 


Registry MIB. 


A row in the service registry table [2] is defined as: 


AtmfSrvcRegEntry ::= SEQUENCE { 
atmfSrvcRegPort INTEGER, 
atmfSrvcRegServiceID OBJECT IDENTIFIER, 
atmfSrvcRegATMAddress AtmAddress, 
atmfSrvcRegAddressIndex INTEGER, 
atmfSrvcRegParml OCTET STRING 


} 
The definition of each field in this structure is: 


atmfSrvcRegPort - The ATM port number for which this entry 
contains management information. The value of zero may be used 
to indicate the ATM interface over which a management request 
was received. 


atmfSrvcRegServiceID - This is the service identifier that 
uniquely identifies the type of service at the address 
provided in the table. (See Section 3.2 for ATMARP OID.) 


atmfSrvcRegATMAddress - This is the full address of the service. 
The ATM client will use this address to establish a connection 
with the service. 


atmfSrvcRegAddressIndex - An arbitrary integer to differentiate 
multiple rows containing different ATM addresses for the same 


service on the same port. 


atmfSrvcRegParml - An octet string whose size and meaning is 
determined by the value of atmfSrvcRegServiceID. 


The service registry table is indexed by atmfSrvcRegPort, 
atmfSrvcRegServiceID and atmfSrvcRegAddressIndex. 
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3.1 Service Parameter String 
A generic parameter string is defined in the service registry table, 
thus allowing protocol-specific parameters to be specified. To be 
consistent with [1], the parameter string for ATMARP shall be: 
arSpro 16 bits Protocol type 
arSplen 8 bits Length of protocol address 


arSaddr plen octets Network address 
arSmask plen octets Network mask 


Where 


arSpro - see Assigned Numbers for protocol type number for 
protocol using ATMARP. (IPv4 is 0x0800, IPv6 is 0x86DD) 


arSplen - Length of the protocol address. (IPv4 is 4, IPv6 is 16) 
arSaddr - Network address represented in network byte order 


arSmask - Network mask represented in network byte order 


3.2 Service Object Identifier 


This OID, assigned in the ATM Forum Service Registry MIB, names 
ATMARP within the context of server discovery. 


atmfSrvcRegATMARP OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.353.1.5.3 } 


It does not name any managed objects, rather is used to locate 
appropriate rows in the service registery table. 


4. ATMARP Client Behavior 


An ATMARP client will access the service registry table via ILMI 
using the SNMP GetNext operator to "sweep" (SNMP parlance for a 
linear search) beginning with {Port = 0, ServiceID = <see Section 
3.2>, Index = 0} while holding the port number and the serviceID 
constant. (Port number 0 is used within ILMI to indicate "this 
port.") 


An ATMARP client with no local configuration, such as a diskless 
workstation, must use the row with the lowest index value if multiple 
ATMARP servers, possibly for multiple networks, are listed. 


ATMARP clients that have local IP configuration must use a row that 
has the appropriate IP address. For example, consider the case where 
an IP router has 3 logical interfaces defined on a single physical 
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interface with IP addresses 1.0.0.1/8, 128.10.0.1/16 and 
171.69.150.226/24. The router will sweep the service registry table 
looking for rows that have atmfSrvcRegParml values as shown below: 


Network number/mask atmfSrvcRegParml 


1.0.0.0/8 08 00 04 01 00 00 00 ff 00 00 00 
128.10.0.0/16 08 00 04 80 Oa 00 00 ff ff 00 00 
171.69.150.0/24 08 00 04 ab 45 96 00 ff ff ff 00 


When the correct atmfSrvcRegParml values are located, the router may 
then establish an SVC to the selected server and perform the 
appropriate protocol operations. 


Redundant ATMARP servers are supported with multiple rows in the 
service registry table. This list of ATMARP servers is ordered with 
the primary ATMARP server having the lowest index value. The ATMARP 
client must attempt to utilize the primary ATMARP server before 
utilizing a secondary ATMARP server. Administrators must ensure that 
the listed ATMARP servers are synchronized. 


ATMARP Server Behavior 


An ATMARP server shall be locally configured. The ATMARP server may 
retrieve the ATMARP service registry data to validate the results. If 
an incorrect row is retrieved the error may be flagged in a locally 
significant way. 


Relationship with PNNI Augmented Routing 


An augmented version PNNI ("PNNI Augmented Routing," or PAR) [3] has 
been developed by the ATM Forum. PAR can distribute data such as 
ATMARP server addresses. Further, the ATM Forum is developing a proxy 
mechanism for PAR (Proxy PAR) that would allow a UNI-attached host or 
router to access PAR data without a full PAR implementation. These 
mechanisms offer a promising way to manage the service registry 
tables maintained on each switch in an ATM network, yet would not 
require changes to the mechanism defined in this memo. Hosts and 
routers can continue to utilize ILMI-based or Proxy PAR-based server 
discovery and network administrators could manage the service 
registry data with local configuration or via PAR and Proxy PAR. 
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7. Security Considerations 


The server discovery mechanism is built on the ILMI managment 
framework and the security embodied in that framework. Access, to 
user- or network-side information is controlled by MIB design rather 
than protocol security mechanisms. 


The service registery MIB, the table containing information for 
server discovery, is defined in [2] with read-only access. This means 
that any user-side device may query the service registry, but may not 
modify the service registry via ILMI. Instead, the sevice registry 
table must be modified via local configuration on the ATM switch. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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